home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1999 March / EnigmA AMIGA RUN 35 (1999)(G.R. Edizioni)(IT)[!][issue 1999-03].iso / earcd / devel / wild / appunti / fasttexture.txt < prev    next >
Text File  |  1999-01-01  |  5KB  |  117 lines
  1.  
  2. Uhm... what about doing something good & fast !?
  3.  
  4. What can speedup a texturemapped drawing module !?
  5.  
  6. 1) Elimination of useless pixels: use scanline methods.
  7. 2) Longword writes to chunky buffer, if possible: use a tmp register.
  8. 3) Uhm... 3 tables are too much, and also 6bit is too much, because
  9.    in a 256colors palette you will never find so perfect things...reduce!
  10. 4) So, less table-access!
  11. 5) More scanline precalcs.
  12.  
  13. All these have been tested on Escape, and were quite good.
  14.  
  15. 1) Scanline methods. 
  16.    Two methods:
  17.     a)- a MoreCrack.PEngY like (longword scanline buffer, scanlines,
  18.       broker routine, drawing from far to near, TRANSPARENCY PROBLEMS!);
  19.     b)- a dynamic method, with a list-like method. (with also some dynamic
  20.         start-line pointers!?)
  21.    
  22.    a) I think i'll do something with method b. (that is good, but needs LOTS of mem! 4*chunkybuffer!!)
  23.    b) List memory: a fixed size buffer, big enough to contain a good number of scanlines.
  24.        The size should be fixed basing also on the resolution. And, CHECK the buffer, 
  25.        to avoid overflows. Maybe, increase it dinamically!
  26.       
  27.       Scanline struct:
  28.        NEXT.l
  29.        (PREC.l)        I think i can obmit it... i hope so...
  30.        FLAGS.b        For special scanlines: transparent !!
  31.        HOLE00.b
  32.        ID.w        Polygon ID.
  33.        LEN.w        Scanline LEN.
  34.       
  35.       The starting buffer may be filled with a scanline for every row: a single
  36.       scanline would overflow in LEN, and would be difficult to manage (there is
  37.       no y anywhere!). 
  38.       
  39.       The direction:  
  40.        a) near to far;
  41.        b) far to near;
  42.       
  43.       a) It's good because you have not to add useless scanlines: if a scanline
  44.          is back another, you can skip it suddently. With transparencies: they
  45.          are flagged, so then it's easy to make a specific case for back-transparent
  46.          scanlines. Good also because you can manage hard cases: a transparent back
  47.          a transparent: you have suddently the case, so you can decide if skip it or
  48.          what. It's bas to manage the background and the starting situation.
  49.          
  50.       b) It's bad because you must do even scanlines that then will be covered;
  51.          for transparents, it's a bit better, because when you covered all transparent
  52.          scanlines with the transparent, you haven't to do more.
  53.          
  54. 2) A quite old idea, but never implemented, and not so easy: a tmp register, common
  55.    to all drawing routines (plain,textured,shaded,bright,burning,...so, i can stop
  56.    when i want with one and start with another) used to write to mem. Check if it is
  57.    a good idea, to comply the source: i want a good performance to do that !
  58.  
  59. 3/4) Table reduction:
  60.    In a 256color palette, i think it's good if i find 4bit precision.
  61.    To reduce the number of accesses: I can do 2 tables instead of 3 (1 table is
  62.    too much big: 1MB!). A table would correct the R, and another the GB. (so,68k)
  63.    Correction tables: Light scaling table (cuts the light)
  64.                  Add table (adds the components to the color)
  65.   
  66.    Better: A Table working on R|GB to .... (working on PAL not on R|GB,something? think!)
  67.    
  68.    And what about R|G|B tables, to allow more tables-> more effects,like alpha channel?
  69.    (imagine R|G|B tables to cut light with alpha channel: for lights is not useful,
  70.     buf i wuold be able to make textures with alpha channel!)
  71.    Needed: (4k*3)*alphashades.
  72.    So: 12k*32 alphashades =384k ! not too much !
  73.    Using 16 shades: 192 k !! better !!
  74.    
  75. 5) During the Sbima writing, i 've seen i need a LOT of mem read/write to update
  76.    the steps, and i have to load every time them. 
  77.       
  78.    See the needed r/w for every x,tx,ty,i,.. update:
  79.    
  80.     r: the y
  81.     r: the cy
  82.        cmp them
  83.     r: the value
  84.        if to update
  85.     r: the step
  86.     w: the new value
  87.     r: the changey  
  88.        cmp with cy
  89.        if to update       
  90.     r: the newstep
  91.     w: the newstep over the oldstep    (media: 5r 1w) for scanline
  92.                         (max:   6r 2w) for scanline
  93.    
  94.    With a precalced expanded scanline (comprending also the inits and steps) :
  95.    
  96.    - precalc cycle: (done polygon by polygon)
  97.     
  98.     (h=have in registers)
  99.     h: y (=cy)
  100.     h: the value
  101.     h: the step
  102.     w: the value
  103.     h: changey
  104.        if to update
  105.     r: the newstep
  106.     
  107.    - draw cycle:
  108.     r: the value            (media: 1r 1w for scanline)
  109.                         (max:   2r 1w for scanline)
  110.     
  111.    The more memory needed is not so much: 10 bytes max for scanline (x.l tx.w ty.w i.w)
  112.    Maybe even less (x.w tx.b ty.b i.b)
  113.    
  114.    More advantages: the precalc may stay in cache (256bytes) and be more pipelined.
  115.  
  116.    EVEN BETTER: Do that in the ScanlineMaker loop !? The first done ARE SURE TO BE
  117.    USED! So, no useless calcings!!